Format

The expressions should live in their own file inside plugin.jar!META-INF/ and not be part of the plugin-descriptor, as the latter one is already too big and complicated. We should update the plugin verification tool in a way that a developer can cross check that the names for types and metrics in the expression match the ones from the descriptor.

The format of the template could be anything - I would expect not to use XML, as any of those reserved chars like <,>,& etc.
would need CDATA sections

JSON or Yaml come to mind. The following shows an example on how this looks like in JSON:

{ "expressions": [
   { "name": "Group EAP6 standalone servers",
      "expression": ["groupby resource.type",
                "resource.type.name = EAP6 Standalone Server",
                "resource.plugin.name = AS7 plugin"],
      "deployByDefault": true,
      "recalcInMinutes": 5
      "description": "This template deploys a dynagroup that will contain all EAP6 standalone servers"
   },
   { "name": .... }
 ]
}

Inside the individual expression, we would have a name/description that is shown in the drop down and the template text. In the above example individual lines of the template are put into elements of an array of strings that is then (literally) put into the editor textbox.

As more than one plugin could define an expression with the same name, we need to make sure that the display for the user includes the plugin name as first part of the name (if we stay with a dropdown); if we create a more sophisticated editor, we should allow to sort by plugin name and expression name.

The above example contains two more entries that may need explanation:

• deployByDefault : if this is present and set to true, then we will on deploy of the plugin create a DynaGroup from the entry. And probably also:

• recalcInMinutes: automatically recalculate the expression every given minutes. A value of 0 switches recalculation off. Only positive integer values are allowed

Server side storage

We could store the expressions in the database in a separate table (possibly just the whole JSON string in a clob). Deploying a new plugin would add new templates, update existing and remove ones that are no longer in the plugin. As alternative we could also leave them in the plugins and dynamically populate the dropdown / list of templates from the plugins when the user wants to create a new DynaGroup. This is possible as we do not relationally refer to the templates, but copy their content when the user selects one.

UI handling

As the list could grow large with many plugins, we should think of allowing to filter entries

• by name

• by plugin

As we already have the DynaGroup-Wizard and the input field to write such expressions, a user with INVENTORY_MANAGER could get additional buttons and fields to store such an expression and also remove user generated expressions. The user generated expressions could get a "plugin name" of "User" (or " User" to sort them in the list to the top). or similar. Also we must make sure that the canned expressions will now show the delete button.

Agent side handling

Agents do not need access to the dynagroup expressions, so they do not need to touch or parse that descriptor

Lifecycle on the server

When a plugin is parsed on the server, the canned expressions are just added to the list of available expressions if they are not yet there. If they already exist, they are replaced. Expressions for a plugin that are no longer provided by the plugin are deleted.

When a plugin is deleted (removed, purged, killed) the expressions of it are removed - especially as killing a plugin also removes all its resource types and resources of that type.

User defined expressions just stay until the user cleans them up.